Dead reckoning in a gaming environment

ABSTRACT

Client position in a multi-client game is determined using dead reckoning. Clients send information to a server over a network. The server distributes this information to other clients. A client uses this information and dead reckoning to determine a character&#39;s position. The server may calculate the client&#39;s position using dead reckoning and send updates to clients when errors between actual and calculated positions exceed a threshold. Clients may calculate their position according to dead reckoning, and when an error between actual and calculated position exceeds a threshold, send updated information to other clients. This Abstract is provided for the sole purpose of complying with the Abstract requirement rules that allow a reader to quickly ascertain the subject matter of the disclosure contained herein. This Abstract is submitted with the explicit understanding that it will not be used to interpret or to limit the scope or the meaning of the claims.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation and claims the prioritybenefit of U.S. patent application Ser. No. 14/276,896 filed May 13,2014, issuing as U.S. Pat. No. 9,550,112, which is a continuation andclaims the priority benefit of U.S. patent application Ser. No.13/431,682 filed Mar. 27, 2012, now U.S. Pat. No. 8,734,258, which is acontinuation and claims the priority benefit of U.S. patent applicationSer. No. 11/479,829 filed Jun. 30, 2006, now U.S. Pat. No. 8,142,289,the entireties of which are hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates generally to video gaming and, moreparticularly, to on-line video gaming.

BACKGROUND OF THE INVENTION

Growth of the electronic entertainment industry has introduced newchallenges for effectively transferring information between clients, orplayers. For example, many new video games allow multiple players toparticipate in the same game environment. Some newer games supportmultiple clients participating in a game environment using a wide orlocal area network, such as the Internet or other network, to transferdata between the clients.

As video games increase in sophistication and complexity the amount ofdata exchanged between players also increases. The increase in dataexchanged between players places increased demands on the network.Increases in the amount of data transferred between players can causedecreased game performance, even with broadband network connections,such as DSL and cable modems.

Thus, there is a need for improved, more efficient, techniques fortransferring data between players in an electronic gaming environment.The present invention satisfies this need.

SUMMARY OF THE INVENTION

In accordance with the invention a method and apparatus for improved,more efficient, techniques for transferring data between players in anelectronic gaming environment is described. In one embodiment, clientssend information to a server over the Internet. This client informationmay include, but is not limited to, character position, charactervelocity, character acceleration, and non-character information that mayrelate to the client's ability to process data in a timely manner. Theserver sends client information for other clients to each client. Theclient uses dead reckoning to determine the position of the character onthe other clients. In one embodiment, the server also calculates all ofthe clients position using dead reckoning and sends updates to clientswhen errors between one of the characters actual position and deadreckoning position exceeds a threshold for that client. In otherembodiments, clients can calculate their own position according to deadreckoning, and when an error between their actual position and the deadreckoning position is exceeds a threshold, send updated position andvelocity data to the server or directly to other clients.

In one embodiment of the present invention, a server receives clientinformation including, but not limited to, initial position and velocitydata from a client. The server then sends a portion of that client'sinformation, such as, its position and velocity data to other clients.The server continues to receive client information updates from clientsand may calculate a dead reckoning position for each client. When theserver determines an error between the dead reckoning position and aactual position for any of the clients exceeds a threshold level for anyother client, the server sends updated client information for the clientwho's errors exceed the threshold level to the other clients. Theposition and velocity data can be sent through the Internet or any othernetwork. Also, each client can have a unique error threshold for eachother client. That is, individual error thresholds can be set forindividual clients relative to each other.

In another embodiment client sends its client information to a server.The client also receives client information of other clients from theserver. The client then calculates a dead reckoning position for theother clients. The client also determines if updated client informationhas been received from the server, and if it has, updates the clientinformation for the other clients in response to updated informationreceived from the server.

In yet another embodiment a client sends client information directly toother clients, and receives client information direct from the otherclients in a peer-to-peer configuration. The client calculates a deadreckoning position for itself and the other clients. The clientdetermines if an error between its calculated dead reckoning positionand its actual position exceeds a threshold level for any other client,and if it does, sends updated client information for itself to the otherclients.

These and other features and advantages of the present invention will beappreciated from review of the following detailed description of theinvention, along with the accompanying figures in which like referencenumerals refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the present invention taught herein areillustrated by way of example, and not by way of limitation, in thefigures of the accompanying drawings, in which:

FIG. 1 is a block diagram of an exemplary system configured for on-linegaming in accordance with aspects of the invention;

FIG. 2 is a block diagram illustrating an example of information sentbetween multiple clients in an on-line game;

FIG. 3 is a diagram illustrating directions in a game world environment;

FIG. 4 is a flow chart illustrating an example of a dead reckoningtechnique consistent with one embodiment of the present invention;

FIG. 5 is a flow chart illustrating an example of dead reckoning by aclient;

FIG. 6 is a block diagram of another exemplary system configured foron-line gaming;

FIG. 7 is a flow chart illustrating another example of dead reckoning bya client;

FIG. 8 is a block diagram of an exemplary embodiment of a server in amulti-client game system; and

FIG. 9 is a block diagram of an exemplary embodiment of a client in amulti-client game system.

It will be recognized that some or all of the figures are schematicrepresentations for purposes of illustration and do not necessarilydepict the actual relative sizes or locations of the elements shown. Thefigures are provided for the purpose of illustrating one or moreembodiments of the invention with the explicit understanding that theywill not be used to limit the scope or the meaning of the claims.

DETAILED DESCRIPTION

In the following paragraphs, the present invention will be described indetail by way of example with reference to the attached drawings. Whilethis invention is capable of embodiment in many different forms, thereis shown in the drawings and will herein be described in detail specificembodiments, with the understanding that the present disclosure is to beconsidered as an example of the principles of the invention and notintended to limit the invention to the specific embodiments shown anddescribed. That is, throughout this description, the embodiments andexamples shown should be considered as exemplars, rather than aslimitations on the present invention. Descriptions of well knowncomponents, methods and/or processing techniques are omitted so as tonot unnecessarily obscure the invention. As used herein, the “presentinvention” refers to any one of the embodiments of the inventiondescribed herein, and any equivalents. Furthermore, reference to variousfeature(s) of the “present invention” throughout this document does notmean that all claimed embodiments or methods must include the referencedfeature(s).

The explosive growth in the electronic entertainment industry hasintroduced new challenges to support new games, such as on-line games.For example, on-line games may allow multiple clients, or players, inremote locations to interact in a gaming environment. As the clientsplay the game, data relative to the clients is exchanged between themultiple clients. In many games, the clients control the movements of acharacter in the game. As the client moves the character, informationabout that characters movement must be sent to the other clientsparticipating in the game. Transferring the data about a character'smovement can significantly increase the bandwidth requirements of thenetwork.

One feature of the present invention is that it provides a method ofupdating one client's character position and other information onanother client across a network using a dead reckoning technique thatcan reduce the bandwidth required to play a multi-client game across thenetwork.

FIG. 1 is a block diagram of an exemplary system configured for on-linegaming in accordance with aspects of the invention. As illustrated inFIG. 1, the system 100 includes at least one client 102. Typically,there may be multiple clients 102 in the system. The system 100 alsoincludes a server 104 and a network 106 that provides connectivitybetween clients 102 and server 104. The network 106 in system 100 may bereferred to as a client-server network since it comprises a plurality ofclients 102 communicating with a server 104. A network 106 may include awide area network, a local area network, a wireless network, a personalarea network, the Internet, or any other network. As described furtherbelow, in one embodiment, clients 102 send information to server 104. Asused herein “client information” may include but is not limited toinformation related to the game character on the client such ascharacter position, character velocity, and character acceleration. Thisinformation may be expressed in multiple dimensions. Additionally, the“client information” may include non-character information such asinformation related to the client's ability to process data in a timelymanner. Server 104 may then send the client information, or a portionthereof, to other clients 102 participating in the game. To reduce theamount of data that is transmitted across network 106, a form of “deadreckoning” may be used.

FIG. 2 is a block diagram illustrating an example but not a limitationof the of information sent between multiple clients 102 and server 104in an on-line game. As illustrated in FIG. 2, clients 102 may reportlocation information about their respective character to the server 104.This location information may include a position and velocity of thecharacters. In other embodiments, other information, such asacceleration, can also be included in the location information.Additionally, other information may be exchanged between clients 102 andserver 104. This other information may include information related toclient 102's current status such as a “busy signal”.

FIG. 3 is a diagram illustrating directions in a game world environment.As illustrated in FIG. 3, position and velocity in the game world can berepresented as either three-dimensions, that is with x, y, and zcomponents, or two-dimensions, with x and z components.

Returning to FIG. 2, clients 102 can report their positions on anyschedule a game designer chooses. For example, the clients 102 canreport their positions at purely periodic times, threshold-based times,or any combination of these two, or by any other schedule. Typically,the schedule is set to ensure accurate reporting of client informationfrom each client 102 to server 104.

In one embodiment, server 104 initially receives and immediately reportseach position and velocity to every other client 102 in the game. Server104 may save a copy of this data for future reference along with thetime the data was received. Server 104 may also save a value called an“error threshold” for each client 102 relative to each other client 102in the game. The error threshold is given by Σ_(k) for the k^(th) client102 in the game. In one embodiment, server 104 may save the followingdata:

-   -   P_(ikx) ^(save) x-position for the i^(th) client 102 last sent        to k^(th) client 102    -   P_(iky) ^(save) y-position for the i^(th) client 102 last sent        to k^(th) client 102    -   P_(ikz) ^(save) z-position for the i^(th) client 102 last sent        to k^(th) client 102    -   V_(ikx) ^(save) x-velocity for the i^(th) client 102 last sent        to k^(th) client 102    -   V_(iky) ^(save) y-velocity for the i^(th) client 102 last sent        to k^(th) client 102    -   V_(ikz) ^(save) z-velocity for the i^(th) client 102 last sent        to k^(th) client 102    -   t_(ik) ^(save) time last data about the i^(th) client 102 was        sent to k^(th) client 102    -   Σ_(k) for the current error threshold

When k^(th) client 102 receives information (from server 104) regardingi^(th) client 102 it may save all of the above data except for Σ_(k)(which it may not receive). The k^(th) client 102 assumes that theposition data it just received regarding the i^(th) client 102 is thepresent position for the player and that future positions are give bythe dead reckoning algorithm:

P _(ix)(t)=P _(ix) ^(save) +V _(ix) ^(save)×(t−t _(i) ^(save))

P _(iy)(t)=P _(iy) ^(save) +V _(iy) ^(save)×(t−t _(i) ^(save))(three-dimensional component saves)

P _(iz)(t)=P _(iz) ^(save) +V _(iz) ^(save)×(t−t _(i) ^(save))

where:

-   -   t is some future time (t≧t_(i) ^(save))    -   P_(i)(t) is an estimate of future position of client i    -   (note the subscript k is unnecessary)

In one embodiment of the present invention the client 102 will continueto use the position calculated by dead reckoning until notifiedotherwise by server 104.

As new client information arrives at server 104 for the i^(th) client102 in the game, server 104 may compute the following error quantity,δ_(k) for each other client 102 in the game (i≠k):

δ_(x) =P _(ikx) ^(save) +V _(ikx) ^(save)×(t−t _(ik) ^(save))−P _(ix)

δ_(y) =P _(iky) ^(save) +V _(iky) ^(save)×(t−t _(ik) ^(save))−P _(iy)

δ_(z) =P _(ikz) ^(save) +V _(ikz) ^(save)×(t−t _(ik) ^(save))−P _(iz)

δ_(k)√{square root over (δ_(x) ²)}+δ_(y) ²+δ_(z) ²

where:

-   -   P_(ix) is the x-position just arrived from the i^(th) client 102    -   P_(iy) is the y-position just arrived from the i^(th) client 102    -   P_(iz) is the z-position just arrived from the i^(th) client 102    -   t is the current time

It should be noted that δ_(k) represents the calculated error betweenthe position just reported by the i^(th) client 102 and the deadreckoning model run by k^(th) client 102 for the i^(th) client 102.

In one embodiment of the present invention server 104 passes on aportion of the client information just arrived from the i^(th) client102 to the k^(th) client 102 only if δ_(k)>Σ_(k). Stated otherwise,server 104 only sends client information if the calculated error betweenthe position reported and the dead reckoning position exceeds the errorthreshold. That is, if the output of the dead reckoning model is deemedto be “good enough”, then the new data is not passed on to client 102,thus reducing the amount of data sent on network 106. One feature ofthis embodiment is that the overall bandwidth usage of the multi-clientgame on network 106 may be reduced.

In another embodiment of the present invention provides a method bywhich a client 102 sends other non-character information to server 104.In this embodiment the other information may contain “busy” or othersignals that indicate that the k^(th) client 102 finds that it is toobusy to process all of the incoming data from server 104, client 102 maysend a message to server 104 indicating this condition. Server 104, inturn, can increase the error threshold Σ_(k) for that client 102. Anincreased Σ_(k) will cause updates to that client 102 to happen lessfrequently thus further reducing the amount of data being sent to thatclient 102 on network 106. This may additionally reduce overall networktraffic. When the k^(th) client 102 finds its processing load returningto normal, a message indicating this fact may be sent to server 104.Server 104 could then decrease error threshold Σ_(k). Several levels oferror threshold Σ_(k) can be defined, thus allowing performance acrossthe network to degrade gracefully in extremely busy network conditions.

In another embodiment, the dead reckoning technique can be performed inonly two dimensions. For example, referring to FIG. 3, one of thecomponents, like the y-component, can be dropped from the dead reckoningcalculation. Reducing the number of components in the dead reckoningcalculation reduces the amount of data server 104 needs to save for eachclient 102. In the example described, the data storage requirement isreduced by approximately one third.

In yet another embodiment, server 104 may treat all clients 102uniformly. For example, when it is determined that updated clientinformation is to be sent, it is sent to all clients 102. In practice,this means that the subscript k can be dropped from the equations above.Treating all clients uniformly greatly reduces the amount of data thatserver 104 needs to store in order to implement the dead reckoningtechnique. One drawback to this embodiment can be if feedback is beingimplemented, in the form of “busy” messages described above, one client102 being overloaded, may cause server 104 to treat all clients 102 asoverloaded. Thus a certain degree of fine-tuning, or network 106bandwidth optimization, may be lost in return for reduced data storagerequirements.

FIG. 4 is a flow chart illustrating an example of a dead reckoningtechnique consistent with one embodiment of the present invention. Flowbegins in block 402 where a client 102's information is received byserver 104. Flow continues to block 404 where the received clientinformation is sent to other clients 102. In block 406 a client 102receives updates on other clients 102 from server 104. In addition toreceiving the actual position of the clients 102, server 104 maycalculate the dead reckoning position for each client 102. For example,server 104 may calculate a dead reckoning position in the same manner asclients 102 are calculating dead reckoning position for other clients102. In this way, server 104 calculates the position that each client102 calculates for the other clients 102, and server 104 also receivesthe actual position of each client 102 from the clients 102 themselves.As noted above, the information sent to other clients 102 may notcontain all information received from client 102.

Flow continues to block 408 where server 104 determines an error betweenthe calculated position and the actual position for each client 102.Then, in block 410 the error in position for each client 102 is comparedagainst an acceptable “error level” or error threshold for each otherclient 102. In one embodiment of the present invention the errorthreshold can be different, for each client 102. In another embodimentthe error threshold may be the same for all clients 102. For example, ina game, if a character on client 102 is a great distance from acharacter on another client 102 in game world environment, the errorthreshold for these clients 102 can be adjusted accordingly. In thisexample, the error threshold for these two clients 102 may be increasedrelative to each other because the clients 102 do not need greatresolution due to their character's relative positions. Likewise, if thecharacter's of two clients 102 are in close proximity to each other inthe game world the error threshold may be decreased so that the clients102 have more accurate information about the position of the characteron the other client 102. Additionally, the client 102's error thresholdmay be adjusted on the basis of other characteristics that include butare not limited to the character's field of view, the clients 102 “busystatus”, or bandwidth considerations on network 106.

One feature of this embodiment is that the bandwidth use on network 106can be optimized to provide more frequent updates to certain clients102, while other clients 102 may receive updates less often. Thisoptimization can more efficiently use the resources of network 106.

In another embodiment of the present invention, server 104 may disregardthe relative position and other characteristics of the clients 102 andmaintain a fixed error threshold for all clients 102. One feature ofthis embodiment is that the calculational requirements is reduced onserver 104. Additionally, the error threshold, once set, may be staticand the need to maintain different error thresholds for each client 102relative to each other client 102 is reduced, further reducing thememory requirement on server 104.

In a further embodiment, server 104 may adjust client 102′s errorthreshold responsive to non-character client 102 characteristics ornetwork 106 characteristics. In this embodiment a client 102 that hassent a busy signal to server 104 may have its error threshold relativeto other clients 102 increased so that it does not receive updates fromserver 104 as often. Additionally, server 104 may monitor network 106traffic and increase all error thresholds for clients 102 as network 106traffic increases thus providing a mechanism for more gracefuldegradation of game performance during peak network 106 traffic periods.

In block 410, if the calculated error exceeds the error threshold, flowcontinues to block 412 where updated client 102 information for theclient 102 who's error exceed the threshold is sent to the other clients102. As stated above, client 102 information is not limited to, but mayinclude character position, velocity, acceleration, character field ofview or non-character client 102 information such as busy signals. Flowthen continues to block 406 and server 104 receives new clientinformation from clients 102. Returning to block 410, if the error doesnot exceed the threshold flow continues to block 406 and server 104receives new client information 102 from clients 102.

FIG. 5 is a flow chart illustrating an example of dead reckoning by aclient 102. Flow begins in block 502 where the client 102 sends it'sclient information to server 104. Flow continues to block 504 where aclient 102 receives the client information of other clients 102 fromserver 104. In block 506 client 102 calculates the position of thecharacters on other clients 102 using dead reckoning. Flow continues toblock 510, where client 102 checks to see if server 104 has sent updateinformation, in the form of an update message, for any of the otherclients 102. If update information has been received, flow continues toblock 512 where the client information for that client 102 is updated.Flow then continues to block 506. Returning to block 510, if no updateinformation has been received, then flow continues to block 506.

FIG. 6 is a block diagram of another exemplary system configured foron-line gaming consistent with embodiments of the present invention. Asillustrated in FIG. 6, there is no server involved in the game. Thisconfiguration may be referred to as a peer-to-peer network since aplurality of clients 102 are communicating directly with each other. Assuch, this configuration is often called a peer-to-peer gamingconfiguration. In this example, clients 102 exchange their clientinformation directly to each other over network 106. Then each client102 calculates each of the other clients 102 character's position usingdead reckoning. In addition, each client 102 may calculate it's owncharacter's position using dead reckoning. When a client 102 determinesthat an error between its character's actual position, and the positionas calculated by dead reckoning, exceeds a threshold for another client102, the client 102 may then send updates of their client information tothat other client 102.

FIG. 7 is a flow chart illustrating another example, consistent with oneembodiment of the present invention, of dead reckoning by a client 102.Flow begins in block 702 where a client 102 sends it's clientinformation to another client 102. Flow continues to block 704 where theclient 102 receives client information from the other clients 102. Inblock 706 the client 102 calculates their character's position, and thepositions of characters on other clients 102 using dead reckoning. Flowcontinues to block 708, where the client 102 checks to see if the errorin their character's actual position compared to the position calculatedby dead reckoning, exceeds a threshold for any other client 102, in theform of an update information message. If it does, then flow continuesto block 710 and the client 102 sends its update client information tothe other clients 102. Flow then continues to block 712. Returning toblock 708, if the error does not exceed an error threshold, flowcontinues to block 712. In block 712 the client 102 checks to see ifclient 102 update information has been received from any of the otherclients 102. If update information has been received, flow continues toblock 714 where the client 102 information is updated. Flow thencontinues to block 706. Returning to block 712, if no client 102 updateinformation has been received, then flow continues to block 706.

FIG. 8 is a block diagram of an exemplary embodiment of a server 104 ina multi-client game system. As shown in FIG. 8, server 104 includes anetwork interface 804. In one embodiment, network interface 804 isadapted to receive client information from a client 102 over theInternet or other network 106. The network interface 804 also sends itsclient information to other clients 102 on the network 106.Additionally, server 104 and network interface 804 are configured toreceive client information from clients 102 throughout the duration ofthe game.

Server 104 additionally comprises a processor 806. The processor 806 maybe configured to calculate a dead reckoning position for each client 102in the multi-client game. The processor 806 may also calculate an errorbased on a calculated dead reckoning position and an actual positionreceived from a client 102. Server 104 may also determine if an errorbetween the calculated dead reckoning position and an actual positionfor each client 102 exceeds a threshold for any other client 102 on thenetwork 106. If server 104 determines an error threshold is exceeded itmay direct network interface 804 to send update client information toclients 102 whose errors exceed the threshold level for the otherclients 102.

FIG. 9 is a block diagram of an exemplary embodiment of a client in amulti-client game system. As shown in FIG. 9, client 102 includes anetwork interface 804. In one embodiment network interface 804 isadapted to send client information to server 104 and to receive clientinformation of other clients 102 from server 104. The client informationmay be sent and received over the Internet or any other network 106. Inanother embodiment, a peer-to-peer configuration as discussed above,network interface 804 may be configured to send client informationdirectly to other clients 102 on network 106 and receive clientinformation directly from other clients 102 on network 106.

Client 102 also includes a processor 806. Processor 806 may be adaptedto calculate a dead reckoning position for each client 102 in themulti-client game. Processor 806 may also be adapted to determine ifupdate client information has been received from server 104, and updateclient information for a client 102 in response to update clientinformation received from server 104. In an alternate embodiment,processor 806 may be configured to determine if update clientinformation has been received from another client 102. In thisembodiment, if update client information is received processor 806 mayupdate client information based on the received information for theother client 102.

In another embodiment, processor 806 may be adapted to calculate a deadreckoning position for its character and the characters of other clients102 on the network 106. Additionally, processor 806 may be configured tocalculate an error based on the calculated dead reckoning position andthe actual position of a character for the client 102 and othercharacters of clients 102 on the network 106. In one embodiment, if acalculated error exceeds a threshold level for any given client 102,processor 806 may direct network interface 804 to send update clientinformation to the other clients 102.

Thus, it is seen that apparatus' and methods for communicating clientdata in a multi-client gaming network are provided. One skilled in theart will appreciate that the present invention can be practiced by otherthan the above-described embodiments, which are presented in thisdescription for purposes of illustration and not of limitation. Thespecification and drawings are not intended to limit the exclusionaryscope of this patent document. It is noted that various equivalents forthe particular embodiments discussed in this description may practicethe invention as well. That is, while the present invention has beendescribed in conjunction with specific embodiments, it is evident thatmany alternatives, modifications, permutations and variations willbecome apparent to those of ordinary skill in the art in light of theforegoing description. Accordingly, it is intended that the presentinvention embrace all such alternatives, modifications and variations asfall within the scope of the appended claims. The fact that a product,process or method exhibits differences from one or more of theabove-described exemplary embodiments does not mean that the product orprocess is outside the scope (literal scope and/or otherlegally-recognized scope) of the following claims.

1. A method for updating character positions, the method comprising:receiving information sent over a communication network from a clientdevice, the received information regarding a character controlled by theclient device and computing resources available to the client device;and executing instructions stored in memory, wherein execution of theinstructions by a processor: modifies a dead-reckoning error thresholdfor the client device based on the available computing resources,provides updates from a server to the client device when adead-reckoning prediction regarding a character of at least one otherclient device exceeds the modified dead-reckoning error threshold,monitors the computing resources available to the client device todetect changes, and updates the dead-reckoning error threshold for theclient device based on the detected changes to the computing resources.2. The method of claim 1, wherein the received information regarding thecharacter includes at least one of a location, velocity, or accelerationof the character within the game.
 3. The method of claim 1, wherein thecomputing resources include at least one of available bandwidth andprocessing capabilities of the client device.
 4. (canceled)
 5. Themethod of claim 1, wherein the modification to the dead-reckoning errorthreshold includes increasing the dead-reckoning error threshold whenthe client device is too busy or would be unable to process all incomingdata from the server.
 6. The method of claim 1, wherein the modificationto the dead-reckoning error threshold includes decreasing thedead-reckoning error threshold when the client device is less busy or isnow able to process incoming data from the server.
 7. The method ofclaim 1, wherein the modification to the dead-reckoning error thresholdis set at pre-determined threshold levels.
 8. The method of claim 1,further comprising instructing the client device to perform a partialdead-reckoning prediction regarding the character of the at least oneother client device based on the non-character information for theclient device.
 9. The method of claim 8, wherein the partialdead-reckoning prediction includes reducing a number of dimensions forcalculating the character information within the game.
 10. A system forupdating character positions, the system comprising: a client deviceparticipating in a network game connected to a gaming network andcontrolling a character within the network game; and a server that:receives information sent over a communication network from the clientdevice, the received information regarding the character and computingresources available to the client device, modifies a dead-reckoningerror threshold for the client device based on the available computingresources, provides updates to the client device when a dead-reckoningprediction regarding a character of at least one other client deviceexceeds the modified dead-reckoning error threshold, monitors thecomputing resources available to the client device to detect changes,and updates the dead-reckoning error threshold for the client devicebased on the detected changes to the computing resources.
 11. The systemof claim 10, wherein the received information regarding the characterincludes at least one of a location, velocity or acceleration of thecharacter within the game.
 12. The system of claim 10, wherein thecomputing resources include at least one of available bandwidth andprocessing capabilities of the client device.
 13. The system of claim10, wherein the modification to the dead-reckoning error thresholdincludes increasing the dead-reckoning error threshold when the clientdevice is too busy or would be unable to process all incoming data fromthe server.
 14. The system of claim 10, wherein the modification to thedead-reckoning error threshold includes decreasing the dead-reckoningerror threshold when the client device is less busy or is now able toprocess incoming data from the server.
 15. The system of claim 10,wherein the modification to the dead-reckoning error threshold is set atpre-determined threshold levels.
 16. The system of claim 10, wherein theserver further instructs the client device to perform a partialdead-reckoning prediction regarding the character of the at least oneother client device based on the non-character information for theclient device.
 17. The system of claim 16, wherein the partialdead-reckoning prediction includes reducing a number of dimensions forcalculating the character information within the game.
 18. Anon-transitory computer-readable storage medium, having embodied thereona program executable by a processor to perform a method for updatingcharacter positions, the method comprising: receiving information sentover a communication network from a client device, the receivedinformation regarding a character controlled by the client device andcomputing resources available to the client device; modifying adead-reckoning error threshold for the client device based on theavailable computing resources; providing updates from a server to theclient device when a dead-reckoning prediction regarding a character ofat least one other client device exceeds the modified dead-reckoningerror threshold; monitoring the computing resources available to theclient device to detect changes; and updating the dead-reckoning errorthreshold for the client device based on the detected changes to thecomputing resources.